This seems in violation of our goals of policy attachment. This means any given configuration can apply to {gateway, route, service} or {route rule, route backend}, but nothing can apply to both. And if its in one category, it has to have one shape and is a backref, and in the other category its in another shape and is a forward ref.

This inconsistency is extremely confusing to users and implementors.

This seems in violation of our goals of policy attachment

This inconsistency is extremely confusing to users and implementors.

I personally disagree. I think allowing/encouraging the same resources/config to be attached with both filters and policy would get more confusing.

The way I look at it, it's potentially confusing to have both policy and custom filters, but this helps limit that by differentiating the two a bit more clearly. I think there are legitimate use cases where custom filters will be easier to work with.

This means any given configuration can apply to {gateway, route, service} or {route rule, route backend}, but nothing can apply to both

That's roughly true, but with policy you still have a lot of flexibility. It's entirely possible to split out Route rules into different Routes if needed for policy attachment. Although not ideal, it does make policy attachment fairly capable. When combined with the ability for policy to attach directly to backends, it seems like there aren't many remaining gaps in policy capabilities.